Method And System For Defining Relationships Among Labels

ABSTRACT

In a content system where labels are used to organize content, relationships between labels may be defined. A relationship may be unidirectional or bidirectional. A label may have multiple relationships to or from other labels. When the user selects a first label, information corresponding to a second label may be displayed in accordance with the relationship between the first and second labels. Relationships between labels may also be inferred by examining the labels and the content associated with the labels.

PRIORITY CLAIM

The present application claims priority to and is a continuation of U.S.patent application Ser. No. 11/731,686, filed Mar. 30, 2007, now U.S.Pat. No. 8,533,232, which is incorporated herein by reference in theirentirety.

TECHNICAL FIELD

The disclosed embodiments relate generally to content categorization,and more particularly, to methods and systems for defining relationshipsamong labels or tags that may be associated with content.

BACKGROUND

The Internet has become a powerful medium for storage and sharing ofcontent. Many web-based services, such as photo-sharing sites, blogs,and social bookmarking sites, are available for users to store contentand to share content with other users. The growth of these services havealso led to the growth of “folksonomy,” in which users categorizecontent by assigning freely chosen keywords, tags, or labels to thecontent.

Folksonomy has some advantages, such as user freedom and its distributednature. However, folksonomy also has some disadvantages. Because of thefreedom of users to make up their own tags, there can be problems withusers making up different tags for the same meaning and tags that mayhave multiple meanings. Furthermore, folksonomies tend to beunstructured. These disadvantages hinder efficient indexing andsearching of tagged content by search engines.

Accordingly, there is a need for a more efficient manner of managingcontent tags.

SUMMARY

According to some embodiments, a method of labeling data items includesidentifying a first label and a second label, the labels being distinctfrom a logical storage scheme associated with the data items; receivinga specification of a relationship between the first label and the secondlabel; associating the first label with the second label in accordancewith the relationship; applying the first label to the data items; andin response to a selection of the second label, presenting informationassociated with the data items based on the relationship.

According to some embodiments, a method of associating labels includesidentifying a first label and a second label that are associated withrespective data items; examining the first and second labels and therespective data items; inferring a relationship between the first labeland the second label based on the examination; and associating the firstlabel with the second label in accordance with the relationship.

According to some embodiments, the aforementioned methods may beperformed by a system having memory and one or more processors.

According to some embodiments, instructions for performing theaforementioned methods may be included in a computer program product.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a computer network, in accordancewith some embodiments.

FIG. 2 is a block diagram illustrating a content server, in accordancewith some embodiments.

FIG. 3 is a block diagram illustrating a client, in accordance with someembodiments.

FIG. 4 illustrates a conceptual diagram of labels and relationshipsbetween labels, in accordance with some embodiments.

FIG. 5 is a flow diagram of a process for defining relationships betweenlabels, in accordance with some embodiments.

FIG. 6 is a flow diagram of a process for examining labels andassociated data items and inferring label relationships from suchexamination, in accordance with some embodiments.

FIG. 7 illustrates an exemplary data structure for storing labelrelationships, in accordance with some embodiments.

FIG. 8 illustrates an exemplary user interface for specifyingrelationships between labels, in accordance with some embodiments.

FIG. 9 illustrates an exemplary user interface for notifying a user ofan inferred label relationship, in accordance with some embodiments.

FIGS. 10-11 illustrate an interface for an exemplary image databasewebsite in accordance with some embodiments.

FIGS. 12-13 illustrate an interface for an exemplary image organizerapplication in accordance with some embodiments.

Like reference numerals refer to corresponding parts throughout thedrawings.

DESCRIPTION OF EMBODIMENTS

A user can tag or label content with tags or labels (both “tags” and“labels” are used interchangeably throughout this description) andspecify relationships between individual content items by definingrelationships between the tags or labels. The relationships may beselected from a pre-specified set. Arbitrary relationships may also bespecified. Additionally, relationships between labels may be inferred byexamining the labels and the content associated with the labels.

FIG. 1 is a block diagram illustrating a computer network, in accordancewith some embodiments. The computer network 100 includes one or moreclients 102, a content system 104, and a plurality of hosts 108 hostingdocuments 110. A network 106 interconnects these components. The network106 may include, without limitation, local-area networks (LAN),wide-area networks (WAN), wireless networks, and the Internet.

The clients 102 are devices from which a user 103 may access content.The client may be any device capable of communicating with othercomputers, devices, and so forth through the network 106. Examples ofclient devices may include, without limitation, desktop computers,notebook (or laptop) computers, personal digital assistants (PDAs),mobile phones, network terminals, and so forth. In some embodiments, theclient device includes one or more applications for communicating withother computers or devices through the network 106. Examples of suchapplications include, without limitation, web browsers, emailapplications, and instant messaging or chat applications. The clientdevice may also include utility applications, such ascalendar/scheduling, contact management, and or task managementapplications.

The content system 104 stores content or data items and provides same toclients 102. The content or data items may include documents such as webpages, electronic messages, images, other digital media content such asaudio and video files, links to such, etc. In some embodiments, thecontent system 104 may include one or more content servers.

The content system 104 allows a user to organize content by labeling ortagging the content. A user may assign one or more labels or tags to hiscontent or data items. A label may be completely arbitrary, or may bechosen to provide a hint of the subject matter of the content. A labelmay be assigned to multiple data items, and a data item may havemultiple labels assigned to it.

FIG. 2 is a block diagram illustrating a content server 200, inaccordance with some embodiments. The content server 200 typicallyincludes one or more processing units (CPU's) 202, one or more networkor other communications interfaces 204, memory 206, and one or morecommunication buses 208 for interconnecting these components. Thecontent server 200 optionally may include a user interface comprising adisplay device and a keyboard and/or a mouse (not shown). Memory 206includes random access memory, such as DRAM, SRAM, DDR RAM or otherrandom access solid state memory devices; and may include non-volatilememory, such as one or more magnetic disk storage devices, optical diskstorage devices, flash memory devices, or other non-volatile solid statestorage devices. Memory 206 may optionally include one or more storagedevices remotely located from the CPU(s) 202. In some embodiments,memory 206 stores the following programs, modules and data structures,or a subset thereof:

-   -   an operating system 210 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 212 that is used for connecting        the content server 200 to other computers via the one or more        communication network interfaces 204 (wired or wireless), such        as the Internet, other wide area networks, local area networks,        metropolitan area networks, and so on;    -   user data 214 for storing per-user data;    -   a labeling module 222 for labeling content and setting        relationships between labels; and    -   a relationship discovery module 224 for discovering and        suggesting possible relationships between labels.

The user data 214 stores data and content associated with user accounts215, or with other digital data or content designated by a user (e.g.,images from the World Wide Web or other network 106). The data orcontent stored under a user account 215 may include the following, or asubset thereof:

-   -   content 216, which may include content uploaded to the content        server 200 by the user (or someone else) and documents for which        the user has created links, pointers, or bookmarks;    -   labels or tags 218, for labeling or tagging the content 216;    -   label relationships 220, for specifying relationships between        labels; and    -   a label-content mapping or table 221 for mapping associations        between labels and content or data items.

Each of the above identified elements may be stored in one or more ofthe previously mentioned memory devices, and corresponds to a set ofinstructions for performing a function described above. The aboveidentified modules or programs (i.e., sets of instructions) need not beimplemented as separate software programs, procedures or modules, andthus various subsets of these modules may be combined or otherwisere-arranged in various embodiments. In some embodiments, memory 206 maystore a subset of the modules and data structures identified above.Furthermore, memory 206 may store additional modules and data structuresnot described above.

Although FIG. 2 shows a content server, FIG. 2 is intended more asfunctional description of the various features which may be present in aset of servers than as a structural schematic of the embodimentsdescribed herein. In practice, and as recognized by those of ordinaryskill in the art, items shown separately could be combined and someitems could be separated. For example, some items shown separately inFIG. 2 could be implemented on single servers and single items could beimplemented by one or more servers. The actual number of servers used toimplement a content server and how features are allocated among themwill vary from one implementation to another, and may depend in part onthe amount of data traffic that the system must handle during peak usageperiods as well as during average usage periods.

FIG. 3 is a block diagram illustrating a client 102, in accordance withsome embodiments. The client 102 typically includes one or moreprocessing units (CPU's) 302, one or more network or othercommunications interfaces 304, memory 306, and one or more communicationbuses 308 for interconnecting these components. The client 102optionally may include a user interface 316 comprising a display device318 and an input device 320, such as a keyboard and/or a mouse 320(though the user interface 316 can encompass any alternative arrangementof output and/or input devices, such as devices that employ audio orBraille output, retinal projection, stimulation of other senses, such astaste or smell, or even direct neural stimulation). The memory 306includes random access memory, such as DRAM, SRAM, DDR RAM or otherrandom access solid state memory devices; and may include non-volatilememory, such as one or more magnetic disk storage devices, optical diskstorage devices, flash memory devices, or other non-volatile solid statestorage devices. Memory 306 may optionally include one or more storagedevices remotely located from the CPU(s) 302. In some embodiments,memory 306 stores the following programs, modules and data structures,or a subset thereof:

-   -   an operating system 310 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 312 that is used for connecting        the client 102 to other computers via the one or more        communication network interfaces 304 (wired or wireless), such        as the Internet, other wide area networks, local area networks,        metropolitan area networks, and so on; and    -   a client application 314.

The client application enables users of the client 102 to access thecontent system 104 and hosts 108 (FIG. 1). Examples of clientapplications include web browsers, email applications, and content feed(e.g., Really Simple Syndication, or RSS) aggregators.

Each of the above identified elements may be stored in one or more ofthe previously mentioned memory devices, and corresponds to a set ofinstructions for performing a function described above. The aboveidentified modules or programs (i.e., sets of instructions) need not beimplemented as separate software programs, procedures or modules, andthus various subsets of these modules may be combined or otherwisere-arranged in various embodiments. In some embodiments, memory 306 maystore a subset of the modules and data structures identified above.Furthermore, memory 306 may store additional modules and data structuresnot described above.

FIG. 4 illustrates a conceptual diagram of labels and relationshipsbetween labels, in accordance with some embodiments. Labels andrelationships between the labels may be conceptualized as a directedgraph 400, with nodes in the graph representing labels and the directededges representing the relationships between labels. The edges may beunidirectional or bidirectional, depending on the relationship. Itshould be appreciated that the labels and relationships shown in FIG. 4are merely exemplary and that the labels and relationships may bedifferent from those shown.

The graph 400 includes four nodes representing labels: A 402, B 404, C406, and D 408. The nodes are connected to each other by variousdirected edges. The edges specify the relationships between the labels.For example, nodes A 402 and B 404 are connected by a bidirectional“related_to” edge and a unidirectional “child_of” edge. The “related_to”edge specifies that labels A and B are related to each other. The“child_of” relationship edge specifies that label B is a child of labelA. That is, label B is a sub-label of label A, similar to therelationship between a folder and sub-folders within the folder.

Label nodes A 402 and C 406 are connected by two bidirectional edges:“synonym_of” and “related_to.” These edges specify that labels A and Care synonyms of each other and are related to each other. Label nodes A402 and D 408 are connected by a unidirectional “more_important_than”edge, which specifies that label A (and content associated with label A)is more important than label D (and content associated with label D).

More generally, between any two nodes representing labels, there may beany number of edges, unidirectional or bidirectional, representingrelationships between the labels. An example is shown with regard tolabel nodes C 406 and D 408. Nodes C and D are connected by abidirectional edge “relationship_x” and two unidirectional edges“relationship_y” and “relationship_z,” each going in oppositedirections. It is possible for two nodes to have a unidirectionalrelationship in one direction and another, unrelated unidirectionalrelationship in the opposite direction. A relationship edge isrepresented by a bidirectional edge if the relationship is mutual. Forexample, synonym and related-to relationships are represented bybidirectional edges because both of these relationships are mutual; “Ais a synonym of B” implies a mutual relationship “B is a synonym of A,”and “A is related to B” implies a mutual relationship “B is related toA.” A relationship is represented by a unidirectional edge if therelationship is not mutual. For example, child-of andmore-important-than relationships are represented by unidirectionaledges because both of these relationships are not mutual. Indeed, aunidirectional relationship often implies an opposite relationship inthe other direction. For example, “A is a child of B” implies theopposite relationship “B is a parent of A,” and “A is more importantthan B” implies the opposite relationship “B is less important than A.”

FIG. 5 is a flow diagram of a process for defining relationships betweenlabels, in accordance with some embodiments. In process flow 500, a userspecifies a relationship between two labels. A user can use these labelsto organize and manage content. Information corresponding to contentassociated with one label may be displayed when another label with whichthe first label has a relationship is selected by the user.

A user accesses his account in the content system 104 and provides afirst label and a second label (hereinafter “M” and “N,” respectively,for convenience) (502). The user may create the label(s), if they havenot been created already. In some embodiments, a label is simply astring of characters. In some other embodiments, a label may include acharacter string and/or an image such as an icon. If the desired labelhas already been created, the user can also select the label from a listof existing labels. In some embodiments, the content system 104 may alsoprovide one or more predefined labels for use by the user.

The user specifies a relationship between labels M and N (504). Therelationship is identified by a character string and/or an image, suchas an icon. The user may select a relationship from a list of predefinedrelationships provided by the content system 104. These predefinedrelationships include ones that are considered to be useful to users intheir content organization and management tasks. These predefinedrelationships have semantic meanings that are known to the contentsystem 104 and that should be apparent to the user from the characterstring identifying the relationship. In some embodiments, the predefinedrelationships include:

-   -   child-of: one label and contents associated with the label are        subordinate to another label within an hierarchy; similar to the        relationship between a sub-folder and a folder;    -   synonym-of: two labels are synonyms of each other or are        equivalents of each other;    -   related-to: two labels are not necessarily equivalents but are        related nonetheless;    -   member-of: one label is a member of a set identified by another        label;    -   more-important-than: content associated with one label has        higher priority than content associated with another label;    -   prerequisite-of: content (e.g., a task in a task list)        associated with one label is necessary to operation of or on        content associated with another label; and    -   current-version-of: content associated with a first label are        the most recent or newest of a class of content that associated        both the first label and the second label.

It should be appreciated that the predefined relationships describedabove are merely exemplary. The content system 104 may provide otherpredefined relationships in addition to or in lieu of those describedabove.

In some embodiments, the user may also create an entirely arbitraryrelationship by entering a character string identifying therelationship. The semantic meaning of such an arbitrary relationship isknown only to the user-creator of the relationship, unlike thepredefined relationships, whose semantic meanings are known to thecontent system 104.

The labels M and N are associated with each other in accordance with thespecified relationship (506). The labels are applied to respectivecontent or data items (508). That is, the content or data items aretagged with the labels and are associated with the labels in the contentsystem 104. The content associated with the labels, including contentthat was associated with the labels before the creation of therelationship, are associated with each other in accordance with therelationship. The associations between labels and data items may bestored as a table of label-data item associations or some other sort ofmapping from labels to data items or vice versa.

The user may later select one of the labels, say label M, in order toview information associated with that label (510). In some embodiments,the user can select the label by clicking on the label in the userinterface. Information corresponding to content or data items associatedwith labels having a relationship with label M may be displayed to theuser, in accordance with the relationship between labels M and N (512).For example, if label M is related to label N, then if label M isselected, information corresponding to content associated with label Nmay be displayed as related to label M. As another example, if contentassociated with labels M and N are tasks in a task list and label N is“a prerequisite of” label M, then when label M is selected, tasksassociated with label N may be shown as prerequisites to the completionof tasks associated with label M.

FIG. 6 is a flow diagram of a process for examining labels andassociated data items and inferring label relationships from suchexamination, in accordance with some embodiments. Process flow 600describes a process in which the content system 104 may infer andsuggest label relationships to a user based on how the user (and, insome embodiments, other users) has labeled his content.

A set of labels and content associated with the labels are identified(602). The labels and the content are examined (604). In someembodiments, the examination includes examining the labels forsimilarity, common substrings, etc. and examining active associationsand relationships between labels and content. In some other embodiments,the examination goes further and actually examines the contentthemselves.

In some embodiments, the examination includes applying pre-specifiedrules to the labels and content. The rules specify the circumstancesunder which a relationship between two labels may be inferred. Forexample, a rule may specify that if the content associated with a firstlabel is a proper subset of content associated with a second label, thenpossible label relationships that may be inferred include, among others,a hierarchal or a “related to” relationship. In some embodiments, therelationship between respective labels may be discovered using a programthat automatically evaluates the relatedness/similarity between thewords and phrases that compose the labels.

For one or more pairings amongst the set of labels, relationships areinferred based on the examination (606). The inferred relationships aresuggested to the user for creation (608). If the user accepts asuggestion (610—yes), then the corresponding relationship is created andthe labels in the inferred relationship are associated with each otherin accordance with the inferred relationship (612). If the suggestion isnot accepted (610—no), then the suggested relationship is rejected(614).

In a large body of collaboratively-tagged data, there will be a lot ofredundancy and discrepancy between tags. For example, FIG. 11 shows thelabels “SF,” “San Francisco,” and “Frisco,” all of which presumablyrefer (redundantly) to the city of San Francisco. In some embodiments,if many people are tagging content, these tags could be appliedredundantly to the same item, in whatever way makes the most sense to anindividual user. From this redundant tagging, relationships can beinferred. For example, while most users might tag information about SanFrancisco as “san francisco”, some might prefer “SF” or “Frisco.” So,for example, if twenty percent of things tagged “san francisco” are alsotagged “SF” or “Frisco”, then in some embodiments it can be assumed thatthe former term (“san francisco”) is at least 20% related to the latter(“SF” or “Frisco”).

Conversely, if things tagged with the less-popular labels “SF” or“Frisco” are also tagged “San Francisco”, then that implies an 80%relationship in the other direction—a user looking at items tagged “SF”is 80% likely to also be interested in items tagged “San Franscisco.” Inthese embodiments the set of things tagged with the more popular termmostly contains the set of things tagged with the less-popular term, so,in the present example, it can be assumed that the labels “SF” and“Frisco” are very likely to related to the same thing as the label “SanFrancisco”.

In other words, some embodiments can use the redundancy anddiscrepancies amongst the terms or labels used by various users to taginformation to suggest relationships between those terms or labels.

In the embodiments described above the relatedness between labels isderived from data entered by multiple users who are tagging/labeling thesame set of data. An example of an application where this might occur is“image search,” where everyone is looking at the same pictures. Impliedrelationships derived from tags or labels can also be applied tosituations where only one person does the tagging—such as in relation toa personal photo collection. This is because in a variety of embodimentsthe implied relationships derived from the tags can be applied to anyset of tagged data based on knowledge of relationships between the tags,or labels.

FIG. 7 illustrates an exemplary data structure for storing labelrelationships, in accordance with some embodiments. The relationshipsbetween labels may be stored in the content system 104 in a table datastructure 700. The table 700 stores relationships 702. Each relationshipdefines a row in the table. In some embodiments, the relationships arestored as character strings identifying the relationship. Each row alsostores the two labels 704, 706 involved in the relationship. Forunidirectional relationships, a label column 704 may be predefined to bethe “tail” of the relationship, and the other label column 706predefined to be the “head” of the relationship. That is, aunidirectional relationship is directed from the tail label in column704 in the corresponding row to the head label in column 706 in thecorresponding row. For example, row 708 specifies that the label“AcmeCo” is a child of the label “Clients.” The relationship “child_of”is directed from tail label “AcmeCo” to head label “Clients.” Moregenerally, the table 700 may store any pair of labels associated witheach other by a relationship, whether unidirectional or bidirectional.In some embodiments, the table 700 does not indicate whether arelationship is unidirectional or bidirectional. For pre-maderelationships, the directions of the relationships are known to thecontent system. User-created relationships may be treated asbidirectional. In some other embodiments, the table 700 may indicate thedirection of the relationships.

FIG. 8 illustrates an exemplary user interface for specifyingrelationships between labels, in accordance with some embodiments. Insome embodiments, a user's labels and label relationships may be viewedby the user from a web browser. From a web browser window 800, the usermay access an interface for reviewing and editing labels andrelationships between labels. An exemplary labels and relationshipsinterface may include a plurality of pull-down menus 804, 806, 808. Afirst label menu 804 shows the list of labels under the user's accountand also allows the user to type in a new label. A relationships menu806 shows a list of available relationships and also allows the user totype in a new relationship. A second label menu 808 also shows the listof labels under the user's account and also allows the user to type in anew label.

To create a relationship, the user types in or selects a first label inthe label menu 804, a second label in label menu 808, and types in orselects a relationship in the relationships menu 806. The user may thenclick a submit button 818 to create the relationship or click a cancelbutton 820 to cancel. If the selected relationship is a unidirectionalrelationship, then the first label may be treated as the “tail” and thesecond label as the “head” of the relationship.

The interface may also show a table 802 of active label relationships.The table 802 includes a tail label column 810, a relationships column812, and a head label column 814, similar to the table data structure700. The table 802 may also include checkboxes 816 where the user canindicate relationships to be removed (deleted) upon clicking of thesubmit button 818.

The interface may also include a tool for deleting labels (not shown).When a label is deleted, all relationships involving that label aredeleted as well. Content associated with the deleted label remains butloses the deleted label.

FIG. 9 illustrates an exemplary user interface for notifying a user ofan inferred label relationship, in accordance with some embodiments. Asdescribed above, the content system 104 may discover possiblerelationships between labels and suggest to the user that such arelationship be created. When the user accesses the labels andrelationships interface via a browser window 800, an alert 902 may beshown whenever a relationship has been discovered. The alert may showthe suggested relationship and ask the user to approve or rejectcreation of the relationship. If the user approves, the suggestedrelationship is created. If the user rejects, the suggested relationshipis not created.

Attention is now directed to applications of labels associated with eachother in accordance with the embodiments described above. FIGS. 10-11illustrate an interface 1000 for an exemplary image database website inaccordance with some embodiments. The exemplary image database websiteinterface 1000 may show one or more images 1010 based on any suitablecriteria, such as the most recently added images or the most frequentlyaccessed images within a specified time frame. The images 1010 in thedatabase may be tagged with one or more tags 1012. Furthermore, the tags1012 may be related to each other in accordance with the embodimentsdescribed above. The interface 1000 also includes a search box 1120 forsearching images based on the tags 1012 applied to the images. In FIG.10, the search query “San Francisco” is typed into the search box 1020.Thus, the query, which in some embodiments is initiated by selection ofa “Search Tags” button 1030, is for images tagged with “San Francisco”or with any tag 1012 that is a synonym of “San Francisco” based on therelationships between the tags. The result of the search is shown inFIG. 11. The images 1010 that are displayed are all tagged with one ormore of “San Francisco” 1042, or synonyms thereof, such as “SF” 1044,“San Fran” 1046, and “Frisco” 1048. It should be appreciated that thesynonyms are recognized as such because a user added the relationshipbetween the tag “San Francisco” and the synonym tags to the imagedatabase. Alternatively, as described above, the relationship betweenlabels and their associated images can be discovered from examination ofredundant or disparate tags assigned to the same images by one or moreusers.

FIGS. 12-13 illustrate an interface 1200 for an exemplary imageorganizer application in accordance with some embodiments. The imageorganizer interface displays a plurality of images 1210. On a sidebar1220 of the interface are labels that have been applied to imagesorganized by the organizer. The labels may be related to one another inaccordance with the embodiments described above. For example, the labels“SF” 1224, “LA” 1226, and “DC” 1228 are children of the label “Vacation”1222. Other possible labels include: “Family” 1230, “Friends” 1232,“Auctions” 1234 and “Miscellaneous” 1236. Selection of the label “SF”1224 by the user brings up the images 1310 associated with the label“SF,” as shown in FIG. 13. The images 1310 are also associated with thelabel “Vacation” because of the child-of relationship between the labels“SF” 1224 and “Vacation” 1222. Also displayed are images 1320 that arenot labeled “SF” but are related to the images 1310 labeled “SF” basedon the relationships between the labels, such as images labeled “LA” and“DC.” The labels “LA” 1226 and “DC” 1228 are related to the label “SF”based on the fact that all three are children of the label “Vacation”1222.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical applications, to therebyenable others skilled in the art to best utilize the invention andvarious embodiments with various modifications as are suited to theparticular use contemplated.

What is claimed is:
 1. A user interface method, comprising: displayingon an electronic display a plurality of labels that can be applied todata items stored on a computer system, such labels being distinct froma logical storage scheme associated with the data items; displaying onthe electronic display a view of at least a subset of the data items;enabling the user to associate with particular ones of the data itemsselected from the view at least one of the labels; displaying on theelectronic display a plurality of relationships that can exist betweenthe labels; enabling the user to define for one or more pairs of thelabels at least one of the relationships; enabling the user to select aspecific label and, in response to such selection, displaying a view ofat least a subset of the data items, wherein the subset of the dataitems is selected from: at least one of the data items associated withthe specific label; and at least one of the data items associated withone or more other labels with a defined relationship to the specificlabel.
 2. The method of claim 1, wherein the defined relationship is anarbitrary relationship between the specific label and the other label.3. The method of claim 1, wherein the defined relationship comprises oneof the group consisting of: a child-of relationship, a synonym-ofrelationship, a more-important-than relationship, a prerequisite-ofrelationship, a member-of-relationship, a related-to relationship, and acurrent-version-of relationship.
 4. The method of claim 1, wherein theuser is a particular user in a plurality of users, further comprising:enabling a first group of at least two of the plurality of users toassociate labels with at least a subset of the data items; and enablinga second group of at least two of the plurality of users to definerelationships among at least a subset of the labels; wherein the subsetof the data items displayed in response to selection by the particularuser of one of the labels is based on the relationships defined for theone label by the second group.
 5. The method of claim 4, furthercomprising: discovering relationships among a second subset of thelabels in view of instances in which different ones of the second subsetof the labels are assigned to a particular data item.